©EST AVAIUVBLE COPY 



Europaisches 
Patentamt 



European 
Patent Office 



[recd 2 VJUN 2004 



iWlPO 



PCT 



Bescheinigung Certificate 



Office europten 
des brevets 



Attestation 



Die angehefteten Unterla- 
gen stimmen mit der 
ursprQnglich eingereichten 
Fassung der auf dem n§ch- 
sten Blatt bezeichneten 
europSischen Patentanmel- 
dung tiberein. 



The attached documents 
are exact copies of the 
European patent application 
described on the following 
page, as originally filed. 



Les documents fix6s d 
cette attestation sont 
conformes d la version 
initialement d§pos6e de 
la demande de brevet 
europten spteifite d la 
page sulvante. 



Patentanmeldung Nr. Patent application No. Demande de brevet 

03101863.3 V 



PRIORITY 
DOCUMENT 

SUBMITTED OR TRANSMITTED IN 
COMPLIANCE WITH RULE 17.1(a) OR (b) 



per President des Europalschen Patentamts: 
im Auftrag 

For the President of the European Patent Office 
Le President de roffice europ6en des brevets 

P.O. 




R C van DIjk 



EPA/EPO/OEB Form 1014.1 - 02.2000 7001014 




Europaisches European Office europeen 

Patentamt Patent Office des brevets 



Anmeldung Nr: / Anmeldetag: 

Application no.: 03101863.3 ^ Date of filing: 25.06.03 J 

Demande no: Date de d^pdt: 



Anmel der/Appl lean tC s)/Demandeur( s) : 

Konlnklijke Philips Electronics N.V. 
Groenewoudseweg 1 
5621 BA Eindhoven 
PAYS-BAS 



Bezelchnung der Erf Indung/Tl tie of the 1 nventl on/Tl tr e de !■ Invention: 
(Falls die Bezelchnung der Erflndung nicht angegeben 1st, slehe Beschrelbung. 
If no title Is shown please refer to the description. 
Si aucun titre n'est Indlqu^ se referer a la description.) 

User-specific interaction with content stored on a UPnP network 

In Anspruch genommene Prloriat(en) / Prlorlty(les) claimed /Pr1or1t6(s) 
revendlqu^eCs) 

Staat/Tag/Aktenze1chen/State/Date/F11e no./Pays/Date/Num^ro de d^pot: 



Internationale Patentklassi f1 kati on/International Patent Classification/ 
Classification Internationale des brevets: 

H04L29/00 



Am Anmeldetag benannte Vertragstaaten/Contracting states designated at date of 
flllng/Etats contractants d^slgn^es lors du d€pdt: 

AT BE BG GH CY CZ DE DK EE ES FX FR GB 6R HU IE IT LU MC NL 
PT RO SE SI SK TR LI 



03101863. 3 

EPVEPO/OEB Form 1014.2 - 01.2000 7001014 



2 



PHNL030717EPP 

1 25.06.2003 
Uso'-spedfic interaction with content stored on a UPnP network 



FIELD OF THE INVENTION 

The invention relates to a nmlti-tiser netwodc, in particular to a netwodc based 
on a UPnP software architecture, that stores an inventor/ of content infbnnation such as 
audio/video (A/V) content items and con^uter games, Ifaat is accessible to multiple users. 

BACKGROUND ART 

Universal Phig and Play (UPnP) is an indusliy-wide ongoing development for 
an open network ardutectore tiiat is designed to enable simple, ad hoc communication among 
distributed devices and software appUcations from multiple vendors. UPnP leverages Internet 
technology and extends it for use in non-supervised home networks. UPnP aims at 
controlling home qipliances, including home automation, audioAddeo, printers, smart 
phones, etc. UPnP distinguishes between Control Points (CPs) and controlled devices (CDs). 
CPs comprise, e.g., browsers running on PCs, wireless pads, etc., that enable a user to access 
Ihe functionality provided by controlled devices. 

UPnP defines protocols for discovery and control of devices by CPs. UPnP 
does not define a streaming mechanism for use by AudioVideo devices. Some of the 
discovery and control protocols are part of the UPnP specification while others are separatdy 
standardized by the IETF (Internet Engineering Taks Force). 

Interaction between CPs and devices is based on the Internet jnotocol (IP). 
However, UPnP allows non-IP devices to be proxied by a software componeat running on IP- 
compliant devices. Such a componeat, called Controlled Device (CD) proxy, is responsible 
for translation and forwarding of UPnP interactions to the proxied device. 

A UPnP device has a hierarchy of sub-devices with at the lowest level 
services. Both devices and servicra have standardized types. A device type determines the 
sub-devices or services that it is allowed to contain. A service type defines actions and state 
variables that a service is allowed to contam. State variables model tbe state of the device, 
acti(SQs can be invoked by a CP in order to chan^ that state. The description of the state 
variables and the actions is called the SCP (Service Control Protocol). A UPnP device 
provides a description of itself in the fiwm of an XML document This document contams. 
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among other tibings, fhe service types that it siq)ports. OpIionaUy, a device may have a 
presentation server for direct Ul control by a CP. 

UPoP relies currently on AutoIP, which provides a means for an IP device to 
get a uniqae address in the absence of a DHCP server. UPnP defines a discovery protocol, 
based on UDP multicast, called SSDP (Simple Service Discovery Protocol). SSDP is based 
on devices periodically multicastmg announcements of the services that they provide. An 
announcement contains a URL to which service actions are to be sent the control server. In 
addition to that, CPs may query the UPhP network for particular device or services types or 
instances. 

UPoP relies on GENf A (Generic Event Notification Architecture) to define a 
state variable subscription and change notification mechanism based on TCP. 

Afi)er a CP has detected a service it wants to use (via SSDP), it controls the 
service by sending SCP actions to the control server URL or querjring for state variables. 
Actions are sent using HTTP POST messages. The body of such a message is defined by the 
SOAP (Simple Object Access Protocol) standard. SOAP defines a remote procedure call 
mechanism based on XML. 

The UPnP AV (audio/video) specification relates to interaction between UPnP 
AV devices, e.g., TV sets, video recorders, DVD players, settop boxes (STBs), PCs, etc., and 
the associated CPs. The UPnP AV specification defines a MediaServer device and 
MediaRenderer device and their services. A MediaServer (MS) on the network stores AV 
content and exposes it to other devices on the network. Content items are stored in a 
hierarchical view, similar to file folders in an electronic filing system on a PC, for example. 
A MediaRenderer (MR) on the network plays back the AV content stored at the MSs. 

SUMMARY OF THE INVENTION 

The home network typically has multiple users. The users may share some or 
all of the content on the network, and they may have diff^ent preferences with regard to 
organizing the content items. For example, a first user wants to have the audio Sle collection 
organized according to artists, a second user wants to organize the same collection according 
to title of the item, etc. Furdier, not all content items may be of interest to each user. 
Especially if the content collection is large, browsing the collection might be fecilitated if die 
system were to pre-select those categories and items that are relevant or of interest to the 
particular user. In addition, privacy or parental control may be issues if there are content 
items on the network, which are not intended or not suitable for being accessed by other 
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users. However, UPnP AV does not provide ways to authenticate different users. Therefore, 
the inventors propose to px>vide personalization, conditional access and security options on a 
UPnP network in order to overcome aforesaid limitation, preferably witiiout afifecting flie 
UPnP middleware layer, without causing conflicts with the UPnP spec., and without making 

5 vendor-specific additions. ' 

To this end, an embodiment of the invention relates to a metiiod of enabling 
multiple users of a UPnP network to access an inventory of content information items stored 
at a MS on tiie netwodc. Hie method comprises enabling to idrntify each respective one of 
die multiple users by means of a respective one of different addresses, contained in a 

10 respective request, e.g., a respective IP-based SOAP request, for access to the MS, and 
enabling to provide respective modes of access to the inventory that are different for the 
respective addresses. In an enibodiment of tiie invention, the respective modes of access 
differ ftom one another with regard to a right to access at least a specific one of the content 
information itmis. For example, one or more items as presented in a graphical representation 

15 of the inventory are accessible to only a specific user or a group of specific users as identified 
by Hieir addresses. Jn another embodiment, the respective modes differ &om one anothCT with 
regard to the representation of the inventory, graphical or otherwise. For example, all users 
but a specific one are blocked firom viewing particular items listed in a representation of the 
inventory, e.g., in a browse or search operation. As another example, different users are 

20 presented different views of the inventory, e.g., based on the users' individual preferences 
such as ranking or organizing of the items in the inventory according to tifle or to performer, 
or according to date and time of the item when first added to the inventory, or to another 
criterion. Again, different users are identified based on their respective addresses so as to be 
able to personalize the representation of the inventory. In another embodiment, the respective 

25 modes of access differ from one another with regard to user interaction allowed with respect 
to at least a specific one of the content information items. For example, a particular user is 
allowed to access and render some items, but not to copy, update or edit these items. As 
another example, some users are allowed to access some items only in a particular time slot, 
and other users in another time slot. This option can be relevant to, e.g,, a parental control of 

30 movies or other audio/video content For exanqple, some movies are siniply blocked from the 
children's view, and others are only accessible in particular time slots because of home work 
or other educative or social duties. 

In case all users have individual CPs, IP-addresses or MAC-addresses can be 
used to identify each respective one of the users and the associated access privileges, ff, on 
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liie other hand, fhe users share CPs in operational use, authentication procedure software 
installed at the CP generates an IP-address per user, e.g., upon a password log-in or 
fingerprint detection. Alternatively, the CP uses multi-homing in order to work with multiple 
addresses on the same network, eadi respective address assigned to a respective user. Multi- 
homing refers to the ability to have a network-enabled device use multiple addresses on the 
same physical network. 

A unique n> may also be embedded as an XML tag in the actual S O AP 
message. In SOAP, arbitrary tags can be added to a message if an ''any" element is present 
An application that does not know the tag will just skip it 11^ however, the ''mustUnderstand" 
attribute has been set to '^ue" and the application does not know tiie tag, the message gets 
refused. UPnP version 1.0 uses SOAP version 0.9 that is ambiguous about adding tags. 
Future versions of the UPnP standard, e.g., UPnP 2.0 andUPnP 1.1, will be using SOAP 1.1 
that explicitiy allows for such a scheme. 

The MS, or another device on the network to which the user identification has 
been delegated, maintains a list of users and/or their associated addresses. The MS then 
generates different views of the object hierarchy for different users. The personalized views 
are specified by the user, i.e. the end-user associated with a particular personalized view, or 
by a special user with administrator rights. Alternatively, the MS can create views in an 
automated way using special rules to create default views, e.g. based on preferences, contoct 
or content type. The devices on the UPnP network see only a single MS advertising itself 
during the discovery phase, but fhe MS exposes different views to different users when 
responding with different results to requests issued by different users. In this manner, content 
that is not intended or suitable for some users is not exposed and, hence, cannot be browsed, 
searched, retrieved, deleted, edited, updated, rendered, etc., by these network users. CPs 
whose IP-addresses are unknown can be given access in a pre-determined default mode, e.g., 
only viewing and rendering access capabilities with regard to content shared by all users. 
Note that it is also possible to create group views, e.g. for content shared by multiple users, 
with this shared content. Accordingly, what has been explained above with regard to 
differentiating between individual users based on their respective addresses can also be 
applied to differentiating between groups of users. A group then comprises one or more 
users, each with a respective address. The addresses per group are associated with a single 
mode of access. 

Another embodiment of the invention relates to software for use on a UPnP 
network with a MediaServer that stores an inventory of contrat information items. The 
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software controls user access to the inventoiy. The software provides or enables to provide 
different modes of access that are different for respective users as identified by respective 
addresses, e.g., IP addresses or MAC addresses, in respective requests for access to the . 
inventory. The software provides the re^ective modes of access that differ from one another 

S with regard to the access to at least a specific one of the content information items. 

Alternatively, or in addition, die software provides the respective modes of access that differ 
fix>m one another with r^ard to user interaction allowed with at least a specific one of the 
content information items. Preferably, the modes of access are programmable (again, by the 
end-user associated with the particular content items or by a special user having administrator 

1 0 rights) when installed on the UPnP network. In this manner, an existing UPnP network can 
be upgraded to accommodating multqile users and to providmg personal interaction modes. 

BRIEF DESCRIPTION OF THE DRAWING 

The invention is explained in fiirther detail, by way of example and with 
1 S reference to the accompanying drawing wherein: 

Fig. 1 is a block diagram of a UPnP network; and 

Fig. 2 is a diagram illustrating the user interaction process. 

Throughout the figures, same reference numerals indicate similar or corresponding features. 

20 DETAILED EMBODIMENTS 

Fig. 1 is a block diagram of a UPnP home network 100 in the invention. 
Network 100 comprises MSs 102,104; MRs 106, 108; and CPs 110 and 112 that 
communicate via an IP-based network 1 14. MSs 102-104 store content information and 
supply it to one or more of MRs 106-108 that render the content information. CPs 110-1 12 

25 serve to provide a user interfece to network 100 in order to control, e.g., at which one of MSs 
102-104 to store a newly acquired content item, browsing and searching of content available 
on network 100; at which one of MRs 106-108 to play out a content item selected fiom the 
inventory of content at a specific one of MSs 102-104, ete. Note that the classification into 
MSs, MRs and CPs refers to fimctionalities, ra&er than to physical entities. 

30 MSs 102-104 are interacted with by multiple users. These users may share part 

of the content stored. However, different users may have different prefermces with regard to 
organizing the content; and not all users have access to each content item. In a UPnP 
environment, as on home network 100, content items are stored in a hierarchical view, 
similar to folders in an electronic file system. As to this hierarchical view, the UPnP AV 
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Content Directory service enumerates content available through the associated MS device. 
The Content Directory service exposes a class hierarchy, which is used to identify all objects 
that can be retrieved fix)m it Each class is named using a string with a pre-deftned syntax. 
Each class defioition inchides a list of properties. Some properties are required while others 
S are optional. Some properties are "multi-valued" for a class, meaning that, in an XML 
instance of the class, the property may occur moro than once. A class that is derived fiom 
another class must include all the required properties of the base class. The definition of a 
subclass may make some optional properties of the base class required. Each property will be 
e>q)ressed in XML as either an XML Element or XML Attribute. Note that these could also 
10 include information on the access rights to generate the personalized views. 

Fig. 2 is a diagram illustrating an example of a process 200 of user interaction. 
Assume that CP 1 10 submits in a step 202 a SOAP request to browse the content inventory 
of, e.g., MS 102. Depending on the implementation of the CP's software the user is to 
e?q)licitiy specify the MS to be accessed, or the software translates the user's request into an 
15 access command to a specific MS. In a step 204, the IP packet containing the SOAP request 
gets parsed and the address (IP or MAC) of CP 110 gets extracted. In a step 206, the address 
thus acquired gets associated with a specific one of multiple users, e.g., according to a pre- 
determined look-up table. In case CP 110 is a personal device or functionality, the IP address 
or MAC address is a unique identifier of the specific user. If on the other hand, e.g., CP 1 10 
20 is heing used by multiple users, different IP addresses are to be generated, one for each user 
interacting through CP 1 10. In that case multi-homing can be employed. Alternatively, an 
authentication process at CP 1 10 is to generate a new JP address based on who has been 
identified by the authentication process. The authentication process may use, e.g., log-in 
passwords or biometrics (e.g,, fingeiprint detection, etc.). The hardware network inter&ce of 
25 CP 108 then uses multiple IP addresses, each of the users then being assigned a fixed and 
personal IP address. Alternatively, the device changes its IP address to the address assigned 
to the person that is currentiy authenticated by the device (assuming only one user can be 
authenticated at a time). 

The process of associating a specific user or user identifier (user ID) with a 
30 specific BP address is carried out by, e.g., CP 1 10, or MS 102 or another component, e.g., a 
device 1 16 on network 100 to which this task h^ been delegated. Based on successful user 
identification, MS 102 generates a view of the content available. Different users may require 
different views. In a step 208, MS 102 uses the user ED found to correspond with the address 
determined in step 204, in order to generate a user-dependent view of the content available at 
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MS 102. Then, in a step 210, MS 102 sends back to fhe address data fhat enable to create thi^ 
view at CP 1 10. Tbis view may have the format of, e.g.» an interactive web page or a 
graphicalrepresentationof afflefoldersystemas ataPCtobepresentedataGinof 110. 
For exaniple, the user can click on items via a touch screen to select them. Above interactions 
have been illustrated with regard to a browse request, but are also applicable to searching, 
adding, editing, updating, eto., of content items. 

On a UPnP level, the browse and search results are sent in DDDLrLite XML 
fragments as specified in the specificatLoiL In order to keep trade of the rights of users with 
respect to specific content items, an administration is maintained that either lists the users 
with their access rights per content item, or lists the content with the rights per user. The 
owner, e.g., the creator of the item or the administrator maintains these lists of access rights 
in a database. This information can possibly be mixed with the DIDL-Lite meta-data 
database. This could be taken care of by using a special UI or a remote application running 
on a different device for convenience, e.g., a PC. The owner or administrator can change the 
rights per user or per content item. In cases where the MS automatically creates content, e.g., 
from recording, special rules could be applied to determine (de&ult) rights upon creation. 

In case of group views the database also needs to keep track of which users 
belong to a specific grotqp and what the rights of these groups are (in order to create the group 
views). These group views can be specific parts in a personalized view. 

Incorporated by reference herein: 

U.S. ser. No. 09/635,548 (attorney docket US 000185) filed 7/25/00 for Jean 
Moonen for UI-BASED HOME NETWORK BRIDGING, and published under PCT as 
WO0209384. This document relates to a home network comprising a UFnP cluster and a 
HAVi cluster. UPnP uses programmatic device interfiices that are based on standardized 
messages being sent between the devices. HAVi also uses programmatic interfaces but needs 
to know the proper device type and FCMs in advance, la addition, the current UPnP and 
HAVi standards do not define devices that can readily be mapped onto one anolfaer owing to 
semantic differences. To overcome this problem, the clusters are bridged by representing a 
UPhP device on the HAVi cluster, wherein the UPnP device's description document is used 
to generate a HAVi DDI target to enable Ul-based control of UPnP devices through a 
HAViUI. 

U.S. ser.no. 09/616,632 (attorney docket US 000184) filed 7/26/00 for Jean 
Moonen and Eugene Shteyn for SERVER-BASED MULTI-STANDARD HOME 
NETWORK BRIDGING, and published under PCT as WO0209350. This document relates 
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to a bridge in a home network that couples first and second clusters of devices. The clusters 
have difTerent sofiware architectures. The bridge is connected to a server on flie Ihtemet. This 
server offers a lookup service for some set of standards, and allows a bridge to locate and 
download the appropriate translation modules for allowing a device in the first cluster to 
S interact with the second cluster. 

U.S. ser jtto. 09/568,932 (attomey docket US 000106) filed 5/1 1/00 for Eugene 
Shteyn and Ruud Roth for ELECTRONIC CONTENT GUIDE RENDERS CONTENT 
RESOURCES TRANSPARENT, pubUshed under PCT as WO0186948. This document 
relates to a data management system on a home network. The system collects data that is 
10 descriptive of content information available at various resources on the network. The data is 
combined in a single menu to enable the user to select from among the content, regardless of 
the resource. 
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CLAIMS: 



1- A method of enabling mtdtiple users of a UPnP network to access an inventory 
of content information items stored at a MediaServer on the network, the method comprising: 

enabling to identify each respective one of the multiple users by means of a 
respective one of different addresses contained in a respective request for access to the 
5 MediaServer; and 

enabling to provide respective modes of access to the inventory that are 
different for the respective addresses. 

2- The method of claim 1, wherein the respective modes of access differ from 
10 one another with regard to rights to access at least a specific one of Ihe content information 

items in the inventory. 

3- The method of claim 1 , wherein the respective modes of access differ from 
one another with regard to user interaction allowed wifli at least a specific one of tiie content 

IS information items in the inventory. 

4- The method of claim 1, wherein the respective modes of access differ from 
one another with regard to a representation of flie inventory. 

^® 5- The method of claim 1, i^erem the respective addresses comprise respective 

IP addresses or respective MAC addresses of respective Control Points on the network. 

6- The method of claim 5, wherein the respective addresses are conq>rised in 

respective SOAP requests to the MediaServer. 



25 



'^^ The method of claim 1, wherein the network comprises a Control Point that 

enables the multiple users to interact with the network, the method comprising enabling the 
Control Point to use dififermt addresses for respective ones of the multiple users. 
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8. For use on a UPnP network with a MediaServer for storing an inventory of 
content information items, software for control of user access to tibie inventory, wherein the 
software provides different modes of access that are difEerent for respective users as 
identified by respective addresses in respective requests for access to the inventory. 

5 

9. The software of claim 8, wherein the respective modes of access difi^ ftom 
one another with regard to rights to access at least a specific one of the content information 
items in the inventory. 

10 10. The software of claim 8, wherein the respective modes of access differ firom 

one another wilii regard to user interaction allowed with at least a specific one of the content 
information items in the inventory. 

1 1 . The software of claim 8, wherein the respective modes of access differ firom 

1 5 one another with regard to a representation of the inventory. 



12. 



The software of claim 8, wherein the modes of access are programmable. 
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ABSTRACT: 



On a UPnP AV network, different users are identified based on respective IP 
addresses in the SOAP requests for interaction with AV content stored on the network's 
MediaServers- Under control of the identity thus determined, the relevant MediaServer 
generates personalized views of the available content, possibly re-organizing content items in 
the inventory overview or blocking items firom being viewed by specific users on the 
network. 



Fig. 2 



1/2 



Control Point 




100 



FIG.1 



PHNIJ030717 

2/2 



User of CP submits IP-based SOAP request - ~-202 
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